Communication devices such as wireless devices may also be known as e.g. user equipments (UEs), mobile terminals, wireless terminals and/or mobile stations. A wireless device is enabled to communicate wirelessly in a wireless communication network and/or over a radio link, with another wireless device and/or radio network node. A wireless device may further correspond to and/or be referred to as a mobile telephone, cellular telephone, laptop, Personal Digital Assistant (PDA), tablet computer, a mobile station, a mobile terminal or a wireless terminal, a mobile phone, a computer such as e.g. a laptop, a Personal Digital Assistants (PDAs) or a tablet computer, sometimes referred to as a surf plate, with wireless capability, a so called Machine to Machine (M2M) device or Machine Type of Communication (MTC) device, e.g. a sensor, i.e. devices that are not associated with a conventional user. A wireless device may be in principle any device or unit capable to wirelessly communicate over a radio link, e.g. in a wireless communication network. The wireless device may be, for example, portable, pocket-storable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data, with another entity, such as another wireless device or a server.
Bluetooth® is a wireless communication technology for exchanging data over short distances. Bluetooth Low Energy (BLE) is a wireless technology for so called Personal Area Networks (PAN) and is designed by the Bluetooth Special Interest Group (SIG) aimed at novel applications in the healthcare, fitness, security, and home automation industries. Compared to Classic Bluetooth, BLE is intended to provide considerably reduced power consumption and cost while maintaining a similar communication range. On the other hand, the amount of data being transmitted by BLE is much less than Classic Bluetooth. BLE is e.g. described in Bluetooth Core Specification 4.2, and is also marketed under the mark Bluetooth® Smart.
The BLE advertising scheme allows a BLE supporting device to periodically broadcast application related data in a predefined format. Four different types of advertisement are utilized in BLE: connectable undirected advertisement (ADV_IND), connectable directed advertisement (ADV_DIRECT_IND), non-connectable undirected advertisement (ADV_NONCONN_IND) and scannable undirected advertisement (ADV_SCAN_IND). Except from ADV_NONCONN_IND, all other advertisements can either be used to explore further information (via so called Scan Request, SCAN_REQ) or create a BLE connection (via so called Connect Request, CONNECT_REQ). Typically, after sending an advertisement, a BLE advertising device turns on a receiver and waits for a short interval to receive reply packets. If a valid packet is received during this interval, the device starts packet processing immediately.
A recipient of the advertisement may in BLE be a so called active scanner, or simply scanner, or a so called initiator. When a scannable advertisement is received, an active scanner sends said Scan Request to the advertiser after an Time interval of Inter-Frame-Space (T_IFS), which is 150 us. No collision avoidance mechanism is defined for BLE message transmission. A back-off algorithm is utilized when an active scanner fails to receive the Scan Response from the advertiser. In the case of an initiator, a Connect Request is sent to the advertiser after T_IFS. According to the specification, an initiator believes the connection is created after the connect request sent to the advertising device, no acknowledgement is needed in this case. However, if the connection failed, it takes 6 times the connection interval, which is defined in the Connect Request.
New usage areas, usage scenarios and applications involving BLE are believed to rapidly grow in a close future. For example, many usage areas and scenarios will likely involve a large amount of different active scanners and/or initiators that want to communicate with one and the same advertiser or at least a smaller amount of advertisers. It is desirable that BLE should be able to manage and robustly support such scenario.